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The Robotics Invention System is an 
outstanding choice for building advanced 
robots. Various types of sensors can be read 
out using the RCX module, and three 
motors or other types of actuators can be 
driven by the pulse-width modulated 
outputs. However, you may sometimes want 
to make a model that needs more power 
than a single RCX module can provide. 
Under the motto ‘strength in unity’, it turns 
out that RCX modules are able to work co- 


operatively. 


After experimenting with the Robot- 
ics Invention System for a while, you 
will notice that the Lego system is 
both powerful and versatile. Still, it 
has its limits. Very complex robots 
may prove to need more active ele- 
ments than can be driven or read out 
by a single RCX block. However, the 
system is flexible enough to be able 
to encompass additional possibili- 
ties, by using the combined forces of 
several modules. The demonstration 
robot shown in the photograph at 


the head of this article is a clear 
example of this. No less than three 
RCX blocks work together in a single 
model, in order to provided the 
desired functionality. One RCX mod- 
ule is built into the transport system, 
while the other two modules work 
together within the robot on the 
basis of clearly divided responsibili- 
ties. All three modules communicate 
with each other regarding the 
progress of their activities. This 
makes it possible to use a specific 
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RCX for each separate function, with 
control being passed to the next RCX 
block on completion of the task. Of 
course, two RCX blocks can also 
carry out tasks independently of 
each other, using messages to keep 
track of each other's processes. Even 
for the novice robot builder, it is not 
especially difficult to utilise the com- 
munication functions of the system 
within the standard development 
environment. 


Communications 


The robots use the infrared trans- 
ceiver that is incorporated in each 
RIS for communicating with each 
other. Codes that are 8 bits wide 
(with numbers between 0 and 255) 
can be exchanged using this inter- 
face. The transmitting robot can 
send a message, which will be 
received by all robots that are within 
the reception range. Whether the 
module that receives the signal actu- 
ally does anything with it depends 
on the software. 

The distance over which the mod- 
ules can communicate with each 
other depends on the settings that 
are made using the configuration 
screen. If the ‘long’ option is chosen 
in this screen, the maximum power 
level is used to send the command. 
Naturally, the distance that can be 
covered is a maximum in this case. 
This configuration option is compa- 
rable to the switch on the infrared 
transmitter that is connected to the 
PC. This switch relates only to the 
output power of the transmitter con- 
nected to the PC. The transmitter 
that is used by the RCX can only be 
configured using software. The 
drawback of high transmission 
power is that the signals may cause 
interference in other systems that 
use RCX modules. In addition, high 
transmission power also causes the 
battery to be used up more quickly, 
particularly if the robots exchange a 
lot of messages. You should therefore 
choose the setting that best fits the 
desired setup. 

Let’s start with message applica- 
tions within the Lego development 
environment. 


RCX-message sensor watcher 
RCX-message sensor watcher is an 
option that is associated with the 
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Figure |. The icons belonging to the message functions in the Lego software. 


standard commands. This blue func- 
tion block represents a function that 
is integrated in the RCX, and that 
can best be compared to a normal 
sensor. The only difference is that it 


does not have to be separately connected. 
This function continuously checks whether 
a message is being received. It causes a sub- 
routine to be executed whenever a message 
is received from another RCX. The command 
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Figure 2. This form can be combined with the Visual BASIC program. The two buttons 
allow the program to be activated in the master and the slave. The result from Label | 
appears at the upper right. Note that the Lego ActiveX module Is linked in. 
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belonging to this function block can be used to 
specify the messages to which the RCX must 
respond. Click on the numbers, and enter the 
lowest and highest message values. The 
linked stack (the Lego term for a subroutine) 


will be executed when a message 
within the message value range is 
received from another RCX. A mes- 
sage may have a value between 0 
and 255. If several RCX modules are 


Table I. The Poll function. 


Poll(Source, Number) 


Source and Number are used to indicate where the Poll function has to look in the RCX. 


Source Number Function 

0 0...31 Variables 0...3 I 

l 0...3 Timer 0...3 

2 z - 

0,1,2 Motor status 

Bit 7: On/Off 1/0 
Bit 6: Brake/Float 1/0 
Bit 5: Output no. HiBit 
Bit 4: Output no. LoBit 


Bit 3: Direction CW/CCW 1/0 


Bit 2: Power Level most significant bit 


Bit |: Power Level 


Bit 0: Powel Level least significant bit 


4 3 2 

5 0,1 No function with RCX 
6 0,1 No function with RCX 
7 2 No function with RCX 
8 

9 


- RCX program number. Number actual program in use 


0,1,2 SensorValue, value measured at input, 


depends on actual mode of operation 


Sensor Type, tells what type of sensor the input is set-up for 
SensorMode, tells what type of sensor the input is set-up for 
SensorRAW i.e. the analogue value measured at the input 
Sensor Boolean, returns the Bololean state of the input 


RCX Watch. Integer where MSB=hours and LSB=minutes 


10 0,1,2 

E 0,1,2 

12 0,1,2 

13 0,1,2 

14 0 

I5 0 Returns the PBMessage stored internally in the RCX 
l6 - No function with RCX 


The result of a Poll instruction that requests data or status is a | 6-bit signed integer. 


Examples of using Poll: 


Labell.Caption = PBrickCtrrl.Poll 0, 7 


Labell takes on the value of Variable 7 in the RCX. 


Label2.Caption = PBrickCtrl1.Poll 8 
Label2 takes on the value of the program being executed by the RCX. 
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used, each module can be assigned 
its own range. A common number 
can be used for broadcasting (com- 
mon messages). 


Reset Message 

In order to prepare a subroutine to 
receive messages, it is necessary to 
first activate the ‘Reset Message’ 
block. As long as this has not been 
done, the RCX will not react to the 
commands. 


Send to RCX 

The ‘Send to RCX’ block allows the 
RCX to send an infrared message to 
another RCX. Needless to say, at 
least two RCX blocks must be used 
in a project before you can make use 
of the communications options. 
When software is being sent from 
the PC to an RCX, only one RCX ata 
time may be on! 


More possibilities with 
Visual BASIC 


Naturally, the features that support 
communications between RCX 
blocks are also available in 
Spirit.OCX, so we can also utilise 
them in high-level languages such 
as Visual BASIC. With such lan- 
guages, it is also possible to have 
the PC actively participate in the 
data traffic. The role of the PC does 
not have to be limited to generating 
code for an RCX and sending out 
program blocks. As we have seen in 
previous instalments, the PC can 
also read out RCX registers (to query 
the battery voltage, for example), 
and it can even request the data 
from an RCX data logging session. 
Unfortunately, though, the PC cannot 
send and receive messages as a sort 
of pseudo-RCX. Spirit.OCX does not 
have any equivalent for the message 
register that is present in the RCX 
module. All in all, this means that a 
PC cannot distinguish between RCX 
blocks, which means that it can only 
communicate with a system that 
contains only one RCX block. Also, 
only one RCX module may be active 
whenever program blocks are being 
transferred from the PC. 

Let’s first have a brief look at how 
we can use a high-level language to 
develop programs that allow RCX 
modules to communicate with each 
other. After this, we will discuss 
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how a PC and an RCX can ‘talk’ to 
each other. 


From RCX to RCX 


Three commands in Spirit.OCX are 
important with regard to exchanging 
messages between RCX modules. 
Two of these (ClearPBMessage and 
SendPBMessage) have equivalents 
in the Lego programming environ- 
ment, and the universal Poll com- 
mand is used to check for successful 
reception. 

Poll is an exceptionally powerful 
and versatile routine, which can 
monitor numerous events in and 
around the RCX block. Table 1 
shows how it can be used. For exam- 
ple, it is possible to use Poll to exam- 
ine registers, to control timers, and 
to monitor motor operation. It can 
also be used is to see if messages 
have been received. A simple BASIC 
program that you can use for exper- 
imenting is shown in Listing 1. 
Actually, this program incorporates 
two different examples, but in prac- 
tice, they can almost never work 
together. 

The program consists of two main 
routines. The subroutine ‘Private 
Sub Up Master Click()’ is a task that 
is placed in program slot 0 of an RCX 
block (RCX program 1). 

After this, there has to be an RCX 
that can receive the message. The 
routine Private Sub Up Slave Click() 
is provided in Visual BASIC for this 
purpose. It places the code for 
receiving a message in the second 
RCX block, and it utilises slot 3 
(SelectPrgm 3, so it can be activated 
as program 4 using the grey Program 
button on the RCX. This is a straight- 
forward routine. When it is first acti- 
vated, it causes the RCX to make a 
sound (PlaySystemSound 
SWEEP DOWN _ SOUND), following 
which it erases the register that may 
hold a message (ClearPBMessage) 
and then waits for the reception of a 
message. If a message is received, 
the same little tune is played again. 
This is naturally only a very simple 
example, but it can be easily 
extended to a more meaningful appli- 
cation. In this example, two tasks are 
carried out in sequence. However, 
since the RCX can perform several 
tasks simultaneously, it is also possi- 
ble to have message monitoring take 
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place in a separate task, in parallel 
with the main task. The structure of 
the program will naturally have to 
take this into account. Listing 2 


shows the approach that must be used. 
Finally, it is naturally also possible to wait 

for a message, and then to start a particular 

task according to the content of the message. 


@ @ 
Listing I. 
Priyatelcubi Timer Timer() 
Rem if label <> 0, RCX has sent the message 
Labell.Caption = Str(PBrickCtrl.Poll(VAR, 0)) 
End Sub 


Private oub Up clave Ciick() 
Rem upload the program for the Slave 
With PBrickCtri 
Rem select program slot 4 
.SelectPrgm 3 


.BeginOfTask MAIN 
Rem let’s hear the program starting 
-PlaySystemSound SWEEP DOWN SOUND 
Rem just to make sure, clear all messages 
-ClearPBMessage 
Rem and wait for message from another RCX 
-While PBMESS, 0, EQ, CON, 0 
Rem 50 ms delay 
-Wait CON, MS_50 
.EndWhile 
Rem message received! 
-PlaySystemSound SWEEP DOWN SOUND 
-EndOfTask 
End With 


End Sub 


Priyate Sub Up master Click() 
With PBrickCtrl 
.SelectPrgm 0 
-BeginOfTask MAIN 
-ClearPBMessage 
Rem just to be safe, make var0 zero 
-SetVar 0, CON, 0 
Rem send message no. 11 
-SendPBMessage CON, 11 
Rem make variable 0 equal to 11 
Rem PC detects ‘message sent’ by reading timer 
-oetVar 0, CON, 11 
-EndOfTask 
End With 
End Sub 


Private Sub Form Load() 
PBrickCtrl.InitComm 
End Sub 
Note: this program utilises the RCXDATA. BAS module, in which the constants (MAIN, 


EQ, CON etc.) are declared and initialised. Make sure that this module is linked in! 


Listing |. The basic program that can be used to analyse the sending of messages. 
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Listing 2. 


:REM structure of a program 
with parallel tasks 


PBrickCtrl.BeginOfTask MAIN 
PBrickCtrl.StartTask 1 
PBrickCtrl.StartTask 2 


PbrickCtrl.EndOfTask 


¿REM definition of tasks within 
MAIN 


PBrickCtrl.BeginOfTask 1 


PBrickCtrl.EndOfTask 


PBrickCtrl.BeginOfTask 2 


PBrickCtrl.EndOfTask 


Listing 2. If the program is set up slightly 
differently, the monitoring of message traffic can 
be carried out in parallel with the main task 


Between PC and RCX 


We have already mentioned that the PC can- 
not participate in the message traffic that can 
take place between RCX blocks. The actual 
problem is primarily that an RCX cannot itself 
send a message to the PC. However, it is pos- 
sible to use a trick to allow the PC to period- 
ically ‘look at’ the RCX to see if it has any- 
thing to report. Note that this trick works only 
with a single RCX; it cannot be used in a sys- 
tem in which several RCX modules are active 
at the same time. 

The trick is based on using an auxiliary vari- 
able in the RCX (VAR 0 in this example). This 
variable has the value ‘0’ after the routine is 
started. After a message has been sent, the 
variable takes on the same value as the mes- 
sage. This is done by the program line ‘Set- 
Var 0, CON, 11’. The number ‘11’ corre- 
sponds to the content of the message, since 
the instruction SendPBMessage CON, 11 is 
defined in the previous line (which is just a 
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coincidence; other values are also 
possible in this application). 

The PC uses a timer to check the 
value of VAR 0 once per second. The 
first few lines of the program show 
how this works. The routine Private 
Sub Timer1 Timer() is used for this 
purpose. With this arrangement, the 
PC uses the Poll command to request 
the content of VAR 0 at one-second 
intervals via PBrickCtrl.Poll (VAR, 0). 
This is controlled by Timer1, which 
has a period of one second. The con- 
tent of the text string obtained in 
this manner is assigned to Label1, 
and then displayed on the screen 
using the form. 

Many readers may wonder what 
this is all good for. The answer is 
that the PC cannot directly receive a 
message from the RCX. However, 
the technique illustrated in this 
example, in which the content of the 
message is assigned to an auxiliary 
variable, makes it possible to check 
whether something has happened 
inside the RCX or has been handled 
by the RCX. This function can be 
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used to send a new task to the RCX 
after it has carried out a particular 
task, or to start a new session after 
the RCX has been read out, for exam- 
ple. 
Now you can probably understand 
why we earlier remarked that these 
two examples are not compatible 
with each other. This is because 
whenever the PC requests the value 
of the auxiliary variable, it would not 
be possible for two or more RCX 
blocks to know which of them 
should send its Variable O value. 
Every block that receives a com- 
mand from the PC will send back its 
own VAR 0 value, which means that 
no reliable result can be obtained in 
the PC. 
Both of these examples are thus 
intended purely to illustrate how var- 
ious things work in the interplay 
between the PC and the RCX or 
between several RCX modules. 
However, it should not be difficult to 
apply these principles to an actual 
robot environment. 
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Figure 3. Thanks to the PBMessages that the RCX blocks can exchange with each 
other, the robots can ‘chat’ with each other. In this example, R2S2 is 
communicating with the robot that will be featured in the next instalment. 
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